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Abstract 

We introduce a systematic, concurrent execution scheme for Constraint Handling Rules 
(CHR) based on a previously proposed sequential goal-based CHR semantics. We establish 
strong correspondence results to the abstract CHR semantics, thus guaranteeing that any 
answer in the concurrent, goal-based CHR semantics is reproducible in the abstract CHR 
semantics. Our work provides the foundation to obtain efficient, parallel CHR execution 
schemes. 

KEYWORDS: multi-set rewriting, constraints, concurrency 



1 Introduction 

Rewriting is a powerful discipline to specify the semantics of programming lan- 
guages and to perform automated deduction. There are numerous flavors of rewrit- 
ing such as term, graph rewriting etc. Our focus here is on exhaustive, forward 
chaining, multi-set constraint rewriting as found in Constraint Handling Rules 
(CHR) (jFriihwirth 1998^ which are used in a multitude of applications such as 
general purpose constraint programming, type system design, agent specification 
and planning etc (jFriihwirth 2006|) . Rewriting steps are specified via CHR rules 
which replace a multi-set of constraints matching the left-hand side of a rule (also 
known as rule head) by the rule's right-hand side (also known as rule body). 

CHR support a very fine-grained form of concurrency. CHR rules can be applied 
concurrently if the rewriting steps they imply do not interfere with each other. An 
interesting feature of CHR is that the left-hand side of a CHR rule can have a mix 
of simplified and propagated constraint patterns. This provides the opportunity for 
further concurrency. We can execute CHR rules concurrently as long as only their 
propagated parts overlap. 

The fact that the abstract CHR semantics is highly concurrent has so far not been 
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exploited in any major CHR implementation. Existing implementations are spec- 
ified by highly deterministic semantics (jPuck et al. 20041 IDe Koninck et al. 2008P 
which support efficient and systematic but inherently single-threaded execution 
schemes (|Duck 20051 |Schrijvers 2005 ). Our goal is to develop a systematic, yet 



concurrent, semantics which can be efficiently executed in parallel on a multi-core 
architecture. In the CHR context, there is practically no prior work which addresses 
this important issue. 

Specifically, we make the following contributions: 

• We develop a novel goal-based concurrent CHR semantics. 

• We verify that our semantics respects the abstract CHR semantics by estab- 
lishing precise correspondence results. 

• We examine which existing sequential CHR optimizations carry over to the 
concurrent setting. 

Section [4] contains the details. A concrete parallel implementation derived from our 
concurrent semantics is studied elsewhere (|Sulzmann and Lam 2008p . Section [521 
provides a summary. 

The upcoming section gives an overview of our work. Section [3] reviews the ab- 
stract CHR semantics. Section[5]discusses prior work on execution schemes for CHR 
and production rule systems which are a related rewriting mechanism. Section [6] 
concludes. 



2 Overview 

We first motivate concurrent execution of CHR rules via a few examples. Then, we 
review existing deterministic CHR execution schemes which are the basis for our 
concurrent goal-based CHR semantics. 



2.1 CHR and Concurrency 

Figures [1] and [2] contain several examples of CHR rules and derivations. We adopt 
the convention that lower-case symbols refer to variables and upper-case symbols 
refer to constraints. The notation rulename@ assigns distinct labels to CHR rules. 

The first example simulates a simple communication channel. The Get{x) con- 
straint represents the action of writing a value from the communication channel 
into the variable x, while the Put[y) constraint represents the action of putting the 
value y into the channel. The interaction between both constraints is specified via 
the CHR rule get which specifies the replacement of constraints matching Get(x) 
and Put{y) hy x = y. The point to note is that in contrast to Prolog, we use 
matching and not unification to trigger rules. 

For example, the constraint store {G'et(m), Put{\)} matches the left-hand side of 
the get rule by instantiating a; by m and y by 1. Hence, {Get{m), Put(\)} rewrites 
to the answer {m = 1}. We write {Get{m), Put{l)} >~*get {m = 1} to denote 
this derivation step. Similarly, we find that {Get{n), Put{8)} >^get {n = 8}. Rules 
can be applied concurrently as long as they do not interfere. In our case, the two 
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Communication channel: 

get@Get{x), Put{y) <;=> x = y 

{Get{m),Put{l)} -^g.t {m = 1} || {Get{n), Put{&)} -^..t {n = 8} 



{Get(m), Put{l), Get{n), Put{8)} ^* {m = 1, n = 8} 

Greatest common divisor: 

gcdi@Gcd{0) <^ True 
gcd2@Gcd{n)\Gcd{m) m > nkkn > | Gcd{m - n) 

{Gcd(3),Gcd(9)} ^gcd2 {Gcd(3),Gcd(6)} 

II 

{Gcd(3),Gcd(3)} ^9cd2 {Gcd(3),Gcd(0)} 



{Gcd(3) , Gcd(3) , Gcd(9) } ^gcd2,gcd2 {Gcd(3) , Gcd(O) , Gcd(6) } 

^* {Gcd(3)} 



{Gcd(3),Gcd(3),Gcd(9)} ^* {Gcd(3)} 
Fig. 1. Communication channel and greatest common divisor 



derivations above can be concurrently executed, indicated by the symbol ||, and 
we can straightforwardly combine both derivations which leads to the final answer 
{m = 1, 71 = 8}. We write ^* to denote exhaustive rule application. 

The answer {m = 8, n = 1} is also possible but the CHR rewrite semantics is 
committed-choice. We can guarantee a unique answer if the CHR rules are confluent 
which means that rewritings applicable on overlapping constraint sets are always 
joinable. In general, (non) confluence is of no concern to us here and is left to the pro- 
grammer (if desired) . We follow here the abstract CHR semantics (jFriihwirth 1998P 
(formally defined in Section |3]) which is inherently indeterministic. Rewrite rules 
can be applied in any order and thus CHR enjoy a high degree of concurrency. 

The key to concurrency in CHR is monotonicity which guarantees that CHR 
executions remain valid if we include a larger context (i.e. store). The following 
result has been formally verified in (|Abdennadher et al. 1999]) . 

Theorem 1 {Monotonicity of CHR) 

For any sets of CHR constraints A,B and S, li A y^* B then S ^* B^ S 

An immediate consequence of monotonicity is that concurrent CHR executions 
are sound in the sense that their effect can be reproduced using an appropriate 
sequential sequence of execution steps. Thus, we can derive the following rule: 

5- tt) 5i ^* 5 W 5*2 ^ W 5'3 ^* 5 W 54 
(Concurrency) 

5 W 51 W 5*3 ^* 5 tt) 52 W 54 
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mergel@Leq{x, a)\Leq{x, b) a < b \ Leq(a, b) 
merge2@Merge{n, a), Merge{n, b) a < b \ Leq{a, b), Merge{n + 1, a) 

Shorthands: L — Leg and M = Merge 

M{l,a),M{l,c),M{l,e),M{l,g) 
^merge2 M(2, fl), M(l, c), M(l, e), L{a, g) 
^^erge2 M{2, a),M{2, c) , L{a, g) , L{c, e) 
^merge2 M{3, a), L{a, g),L{c, e), L{a, c) 

^mergel M(3, ffl), L(tt, c), L(c, 5), L{c, e) 

^mergei M{3, a), L{a, c),L{c, g), L{e, g) 

II 

M(l,6),M(l,d),M(l,/),M(l,/i) 
^* M{3,b),Lib,d),L{d,f),L{f,h) 



,L{a,c),L{c, e),L{e,g),M{3,b),L{b,d),L{d,f),L{f,h) 
,L(a, c),L{a, b),L{c, e), L{e, g), L{b, d), L{dJ), L{f , h) 
,L{a,b),L{b,c),L{c,e),L{e,g),L{b,d),L{d,f),L{f,h) 
,L{a,b),L{b,c),L{c,d),L{c,e),L{e,g),L{dJ),L{f,h) 
,Lia,b),L{b,c),L{c,d),L{d,e),L{e,g),L{dJ),L{f,h) 
,L{a, b),L{b,c),L{c, d),L{d, e), L{e, f), L{e, g), L{f , h) 
,L(a, fe),L(6, c),L(c, e), L{e,f), L{f , g),L{f , h) 

,L{a, b),L{b, c),L{c, d),L{d, e), L{e, f), L{f , g), L{g, h) 



M{l,a),M{l,c),M{l,e),M{l,g),M{l,b),Mil,d),M{l,f),M{l,h) 
^* M{4,a),L{a,b),L{b,c),L{c,d),L{d,e),L{e,f),L{f,g),L{g,h) 



^merge2 
^mergel 
merge 1 
merge 1 

merge 1 
^mergel 



M(3, a) 
M(4, a) 
M(4, a) 
M(4, a) 
M(4, a) 
M(4, a) 
M(4, a) 
M(4, a) 



Fig. 2. Merge sort 



In (jFriihwirth 2005|) . the above is referred to as "Strong Parallelism of CHR". 
However, we prefer to use the term "concurrency" instead of "parallelism". In the 
CHR context, concurrency means to run a CHR program (i.e. a set of CHR rules) 
by using concurrent execution threads. 

Let's consider the second CHR example from Figure [T] which computes the great- 
est common divisor among a set of numbers by applying Euclid's algorithm. The 
left-hand side of rule gcd2 is interesting because it uses a mix of simplified and 
propagated constraint patterns. We replace (simplify) Gcd{m) by Gcd{m — n) but 
keep (propagate) Gcd{n) if the guard m > nSzSzn > holds. For example, we 
find that {Gcd{3),Gcd{9)} >^gcd2 {Gcd{2,),Gcd{Q)} and {Gcd{2,),Gcd{^)} >^g,d2 
{Gc(i(3), Gcd{o)}. The point to note is the above rule applications only overlap on 
the propagated part. Hence, we can execute both rewrite derivations simultaneously 

{Gc(i(3),Gcd(3)Gcd(9)} --2xsc<i2 {Gc(i(3), Gcd(o), Gc(i(6)} 
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Our last example in Figure [2] is a CHR encoding of the well-known merge sort 
algorithm. To sort a sequence of (distinct) elements ei, • • •, Cm where m is a power 
of 2, we apply the rules to the initial constraint store 

Merge{i, ej, • • •, Merge{i, e™) 

Constraint Merge{n, e) refers to a sorted sequence of numbers at level n whose 
smallest element is e. Constraint Leq{a, b) denotes that a is less than b. Rule 
merger initiates the merging of two sorted lists and creates a new sorted list at 
the next level. The actual merging is performed by rule mergei. Sorting of sublists 
belonging to different mergers can be performed simultaneously. See the example 
derivation in Figure [2] where we simultaneously sort the characters a, c, e,g and 
b,dj,h. 



2.2 Goal-Based CHR Execution 

Existing CHR implementation employ a more systematic CHR execution model 
where rules are triggered based on a set of available goals. The idea behind a goal- 
based CHR execution model is to separate the constraint store into two components: 
a set of goal constraints (constraints yet to be executed) and the actual constraint 
store (constraints that were executed) . Previously, in the abstract semantics transi- 
tions are among states Store whereas in the goal-based semantics we find now 
transitions >—fg among states of the form (Goals \ Store). Only goal constraints 
can trigger rules by searching for store constraint to build a complete match for a 
rule head, thus allowing for execution of the rule. 

Below, we give a goal-based execution of the earlier communication buffer exam- 
ple. 



get@Get{x), Put(y) 



y 



{{Get{x^), Get{x2), Put(l), Put{2)} \ {}) 
(Dl Activate) ({Get(2;i)#l, Get(x2), Put{l), Put{2)} \ {Get(a;i)#l}) 

(D2Drop) {{Get(x2),Put{l),Put{2)}\{Get{xi)#l}) 

(D3 Activate) '^g {{Get{x2)#2, Put{l), Put{2)} \ {Get{xi)#l, Get{x2)#2}) 
(D4 Drop) {{Putil), Put{2)} \ {Get{xi)#l, Get{x2)#2}) 

(D5 Activate) ^^g ({Puf(l)#3, Put{2)} \ {Ge<(a;i)#l, Get{x2)#2, Put{l)#S}) 

(D6 Fire get) ^g {{Put{2), xi = 1} \ {Get{x2)#2}) 

(D7 Activate ^g ({Put(2)#3, xi = 1} \ {Get{x2)#2, PMi(2)#3}) 

(D8 Fire get) ^g {{xi = 1, = 2} | {}) 
(D9 Solve) ({X2 = 2} | {xi = 1}) 

(DIO Solve) ({} I {xi ^1,X2 = 2}) 

We label the a;"* derivation step by a label Dx. Let's walk through each of the 
individual goal-based execution steps. Initially, all constraints are kept in the set 
of goals. At this point, all of the goals are inactive. Execution of goals proceeds in 
two stages: (1) Activation and (2a) rule execution, or (2b) dropping of goals. In the 
first stage, we activate a goal. In general, the order in which goals are activated is 
arbitrary. For concreteness, we assume a left-to-right activation order. 

Hence, we first activate Get{xi) in derivation step (Dl). Active goals carry a 
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unique identifier, a distinct integer number. Besides assigning numbers to active 
goals, we also put them into the store. For instance, after activating Get{xi), we 
have Get{xi)^l in both the goals and the store. 

Active goals like Get {xi)#l are executed by trying to build a complete match for 
a rule head with matching partner constraints in the store. Since there are no other 
constraints in the store, we cannot match Get{xi)^\ with the get rule. Therefore 
we drop Get{xi)^l in step (D2). Dropping of a goal means the goal is removed from 
the set of goals but of course the (now inactive) goal is still present in the store. 
Step (D3) and (D4) are similar but executed on goal Get{x2). Then, we activate 
Get{x2) and find that Get{x2)#2 cannot build a complete match of the get rule, 
thus it is dropped too. 

Next, we activate Put{l) (Step D5). Constraint Put{l)^3 can match with either 
Get{xi)#l or Gei(x2)#2 to form a complete instance of rule head of get. We pick 
Gei(a;i)#l and fire the rule get, see step (D6). Step (D7) and (D8) perform similar 
execution steps on Put{2) and the remaining stored constraint Get{x2)4k2. Finally, 
we add the equations xi = 1 and X2 = 2 into the store in steps (D9) and (DIO). 
Exhaustive application of this goal-based execution strategy then leads to a state 
with no goals and a final store. 

What we have described so far is essentially the execution scheme in which all 
major CHR implementations are based on. The semantics of these implementa- 
tions assume a deterministic activation policy. For example, goals are kept in a 
stack (jPuck et al. 2004")) or priority queue ()De Koninck et al. 2008[) . This of course 
implies a strictly sequential execution scheme. 

To obtain a systematic, yet concurrent, CHR execution scheme we adapt the goal- 
based CHR semantics as follows. Several active goal constraints can simultaneously 
seek for partner constraints in the store to fire a rule instance. In the extreme case, 
all goal constraints could be activated at once. However, we generally assume that 
the number of active goals are bounded by n where n corresponds to the the number 
of actual threads available to the run-time system (for example, processor cores). 

Figure [3] shows a sample concurrent goal-based CHR derivation. We assume two 

concurrent threads, referred to as a and &, each thread executes the standard goal- 
's 

based derivation steps. The novelty is that each goal-based derivation step 
now records its effect on the store. The effect 5 represents the sets of constraints in 



Numbered constraints also disambiguate multiple copies in the store but this is rather a side- 
effect. The main purpose of numbering constraints is to indicate activation and retain the link 
between active goal constraints and their stored copy. 
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Short hands: C = Get P = Put 
<{G(xi),G(i2),f(l),-P(2)} I {}> 

(Dla, Activate) ({G(xi)#l, G(i2), f(2)} I {G(=:i)#l}> 

I 

(Dlb Activate) ^i}g^ <{G(xi), G(x2)#2, P(l), F(2)} | {G(x2)#2}> 



{{G(xi), G(»2), J'(1),P(2)} I {}) 
(Dla II Dlb) iX]^g ({G(xi)#l,G(x2)#2,P(l),P(2)} | {G(xi)#l, G(x2)#2}> 

(D2a Drop) ^l}g^ <{G(r2)#2, P(l), P(2)} | {G(ri)#l, G(i2)#2}> 

(D2b Drop) ^« " ({G(xi)#l, P(l), P(2)} | {G(ii)#l, G(x2)#2}) 

({G(xi)#l, G(x2)#2,P(l), P(2)} I {G(xi)#l, G(X2)#2}> 
(D2a II D2b) ii^i^ ({P(1),P(2)} | {G(xi)#l, G(X2)#2}> 

(D3a Activate) ^l}^ <{P(1)#3, P(2)} | {G(xi)#l, G(X2)#2, P(l)#3}> 

II 

(D3b Activate) ^iip ({P(l), P(2)#4} | {G(xi)#l, G(X2)#2, P(2)#4}> 

({P(1),P(2)} I {G(xi)#l, G(X2)#2}> 
(D3a II D3b) liji^ <{P(1)#3, P(2)#4} | {G(xi)#l, G(X2)#2, P(l)#3, P(2)#4}) 

«1 

(D4a Fire get) ({xj = 1, P(2)#4} | {G(X2)#2, P(2)#4}) 

II 

^2 

(D4b Fire get) «g ({P{l)#3,i2 = 2} | {G(ii)#l, P(l)#3}) 
whereSi = {}\{G(xi)#l, P(l)#3} S2 = {}\{G(i2)#2, P(l)#4} 

<{P(1)#3, P(2)#4} I {G(.ii)#l, G(i;2)#2, P(l)#3, P(2)#4}> 

(D4a||D4b) ({xi = 1,X2 = 2} I {}) 

where^ = {}\{G(xi)#l, P(l)#3, G(x2)#2, P(l)#4} 

(D5a Solve) <{X2 = 2} | {xi = 1}> || (D5b Solve) ^"g^ <{xi = 1} | {X2 = 2}> 

({xi = 1,X2 = 2} I {}> 
(D5a II D5b) ii^j,^ ({} I {XI = 1, X2 = 2}> 



Fig. 3. Example of concurrent goal-based CHR derivation 



the store which were propagated or simplified. Goal-based derivation steps can be 
executed concurrently if their effects are not in conflict. 

(Gi I Hsi U Hs2 U S) {Gi I Hs2 U S) 

{G2 I Hsi U Hs2 U S) >i||e (G2 I Hsi U S) 
5i = Hpi\Hsi 82 = Hp2\Hs2 
(Goal-Concurrency) Hn C S Hri C S !) = Hri U Hr2\Hsi U Hs2 



(Gi tbi G2 tbi G I HsiUHs2US} 
^]ig {G( l±J G^ W G I S) 

The (Goal-Concurrency) rule, abbreviated (|| G), states that two goal-derivations 

are not in conflict if their simplification effects arc disjoint and the propagated 
effects are present in the joint store. We will provide more explanations later. Let's 
continue with our example. 
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Each thread activates one of the two Get goals (Steps Dla and Dlb). Since both 
steps involve no rule application, side-effects are empty ({}\{})- Both steps are 

executed concurrently denoted by the concurrent derivation step (Dla||D2a) 
Concurrent goal-based execution threads operate on a shared store and their effects 
will be immediately made visible to other threads. This is important to guarantee 
exhaustive rule firings. 

In the second step (D2a||D2b), both active goals are dropped because there is 
no complete match for any rule head yet. Next, steps (D3a) and (D3b) activate 
the last two goal constraints, Put{l) and Put{2). Each active constraint can match 
with either of the two Get constraints in the store. We assume that active con- 
straint Put{l)^3 in step (D4a) matches with Get{xi)^l, while Put{2)^A in step 
(D4b) matches with Get{x2)#2, corresponding to the side-effects 5i and ^2- This 
guarantees that steps (D4a) and (D4b) operates on different (non-conflicting) parts 
of the store. Thus, we can execute them concurrently which yields step (D4a||D4b). 
Their side-effects are combined as 5. Finally, in step (D5a||D5b) we concurrently 
solve the two remaining equations by adding them into the store and we are done. 

The correctness of our concurrent goal-based semantics is established by showing 
that all concurrent derivations can be replicated by sequential goal-based execu- 
tions. We also prove that there is a correspondence between our goal-based CHR se- 
mantics with the abstract CHR semantics. This proof generalizes from (jPuck 2005^ 
which shows a correspondence between the refined CHR operational semantics and 
abstract semantics. There are a number of subtle points we came across when de- 
veloping the concurrent variant of the goal-based semantics. We will postpone a 
discussion of these issues, as well as a complete formalization of the concurrent 
goal-based semantics until Section E) Next, we formally introduce the details of the 
abstract CHR semantics. 



3 Constraint Handling Rules 

Figure m reviews the essentials of the abstract CHR semantics (jFriihwirth 1998[) . 
The general form of CHR rules contains propagated heads Hp and simplified heads 
Hg as well as a guard tg 

r@Hp\Hs ^tg\B 
In CHR terminology, a rule with simplified heads only (Hp is empty) is referred to 
as a simplification rule, a rule with propagated heads only {Hs is empty) is referred 
to as a propagation rule. The general form is referred to as a simpagation rule. 

CHR rules manipulate a global constraint store which is a multi-set of constraints. 
We execute CHRs by exhaustive rewriting of constraints in the store with respect 
to the given rule system (a finite set of CHR rules), via the derivations To avoid 
ambiguities, we annotate derivations of the abstract semantics with A. 

Rule (Rewrite) describes application of a CHR rule r at some instance cj). We sim- 
ply (remove from the store) the matching copies of (j){Hs) and propagate (keep in the 
store) the matching copies of <j)[Hp). But this only happens if the instantiated guard 
(l){tg) is entailed by the equations present in the store S, written Eqs{S) \= (j){tg). 
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Notations: 

1+) Multi-set union 

\= Theoretic entailment 

(j> Substitution 
■q Set/List of a's 



CHR Syntax: 

Functions / 

Constants v 

Terms t 

Predicates p 

Equations e 

CHR constraints c 

Constraints b 

CHR Guards tg 

CHR Heads H 

CHR Body B 

CHR Rule 7? 

CHR Store S 

CHR Program V 



= + |>| && 
= 1 I true I • 
= x\ft 
= Get \ Put 
= t = t 

-Pit) 
= e I c 
:= t 
:= H 
-b 

= r@H\H ■ 
= 6 



to I B 



Abstract Semantics Rules: 



Store >— >_4 Store 



(Rewrite) 



(Concurrency) 



(Closure) 



{r@Hp\Hs tg \ B) eV such that 
3<t) Eqs{S) ^ (t> A tg (l>{Hp\i)Hs)^ H'p\i)H's 

H'p \i}H's\tiS -^A H'p W 0(5) tbi S 

S \i) Si -^"a S \i} S2 S \^ S3 -^"a S \i) Si 

5 > — ''A S' S 1 — >A S' S' > — >A S" 



S > — >A ^ ^ ' — ^A ^ 

where Eqs{S) = {e|eGS',eisan equation} 



Fig. 4. Abstract CHR semantics 



In case of a propagation rule we need to avoid infinite re-propagation. We re- 
fer to (jAbdennad her 1997|IDuck 2005^ for details. Rule (Concurrency), introduced 
in (jFruhw irtli 20051). states that rules can be applied concurrently as long as they 
simplify on non-overlapping parts of the store. 

Definition 3.1 [Non-overlapping Rule Application) 

Two applications of the rule instances r@Hp\Hs tg \ B and r'@Hp\Hg 
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Notations: 

tU Multi-set union 

U Set union 

^ Theoretic entailment 

4> Substitution 

■q Set/List of o's 



CHR Syntax: 






Functions 




= + |>| && 


Constants 


V :: 


:= 1 1 true \ ■ 


Terms 


t :: 


= x\ft 


Predicates 


p :: 


■- Get\ Put 


Equations 


e :: 


= t^t 


CHR Constraints 


c :: 


= p(t) 


Constraints 


b :: 


= e c 


CHR Guards 


t, : 


:= t 


CHR Heads 


H 


::= T 


CHR Body 


B : 


■-b 


CHR Rule 


R : 


■- r@H\H 


CHR Program 


V : 


■-R 


Num Constraint 


nc 


::= e#t 


Goal Constraint 


9 ■■ 


'— c \ e \ nc 


Stored Constraint 


sc 


::= nc \ e 


CHR Num Store 


Sn 


::= Jc 


CHR Goals 


G : 




CHR State 


a : 


— {G,Sn) 


Side Effects 


5 :: 


= Sn\Sn 



Fig. 5. CHR Goal-based Syntax 



t'g I B' in store S are said to be non-overlapping if and only if they simplify unique 
parts of S (i.e. Hg^H^^CS and n 77^, 0). 

The two last (Closure) rules simply specify the transitive application of CHR rules. 

4 Concurrent Goal-Based CHR Operational Semantics 

We present the formal details of the concurrent goal-based CHR semantics. Figure 
[5] describes the necessary syntactic extensions. Because constraints in the store 
now have unique identifiers, we treat the store as a set (as opposed to a multiset) 
and use set union U. Goals are still treated as multi-sets because they can contain 
multiple copies of (un-numbered) CHR constraints. The actual semantics is given 
in two parts. Figure [6] describes the single-step execution part whereas Figure [7] 
introduces the concurrent execution part. The first part is a generalization of an 
earlier goal-based description ()Duck 2005P whereas the second (concurrent) part is 
novel. 

We first discuss the single-step derivation steps in Figure [6l A derivation step 
a a' maps the CHR state a to a' with some side-effect 6. 6 represents the con- 
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{Goal I Store) {Goal \ Store) 



W = WakeUp{e,Sn) 



(Solve) 



(Activate) 



(Simplify) 



(Propagate) 



(Drop) 



w\{} 

{{e} W G I ^n) >-^g {WWG\{e}U Sn) 
i is a fresh identifier 

({c} W G I ^n) {{c#i} W G \ {c#i} U Sn) 

ir@Hp\Hs tg \B')€V such that 

30 Eqs{Sn) }= A i j 0(F^) = DropIds{Hp) 
<l){Hi;) = 0({c} tbi DropIds{Hs)) 
5 = Hp\{c#j}yjHs 

{{c#j} W G I {c#i} UHp^HsU Sn) 
>4g (0(B') l±l G I i/s U ^n) 

{r@H^\H^ ■^tg\B')eV such that 
30 £;gs(5'n) \= (f) A tg <}){H[;) = DropIds{Hs) 
(l){H'p) = 0({c} i+i DropIds{Hp)) 
5 = {c#j} U ;fp\i7s 

({c#j} a G I {c#j} U i/p U Hs U 5n) 
{0(B')W{c#j}WG|{c#j}UJ^pU5n) 

(Simplify) and (Propagate) does not apply on c#j in Sn 



{{c#:,}^G\Sn)^^g {G\Sn) 



where Eqs{S) = {e | e G 5, e is an equation} 

DropIds{Sn) = {c \ c#i £ Sn} ttJ {e | e G Sn, e is an equation} 
WakeUp{e, Sn) = {c#i \ c#i £ Sn A (p m.g.u. of Eqs(Sn)A 
e m.g.u. of Eqs{Sn U {e}) A 0(c) ^ e{c)} 



Fig. 6. Goal-Based CHR Semantics (Single-Step Execution) 



straints that where propagated or simplified during rule application. Hence deriva- 
tion steps that do not involve rule application ((Activate) and (Drop)) contain no 
side-effects (i.e. {}\{}). We will omit side-effects S as and when it is not relevant 
to our discussions. We ignore the (Solve) step for the moment. In (Activate), we 
activate a goal CHR constraint by assigning it a fresh unique identifier and adding 
it to the store. Rewrite rules are executed in steps (Simplify) and (Propagate). We 
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distinguish whether the rewrite rule is executed on a simphfied or propagated active 
(goal) constraint c#i. For both cases, we seek for the missing partner constraints in 
the store for some matching substitution cj). The auxiliary function Droplds ignores 
the unique identifiers of numbered constraints. They do not matter when finding a 
rule head match. The guard tg must be entailed by the primitive (here equational) 
store constraints under the substitution 0. 

In case of a simplified goal, step (Simplify), we apply the rule instance of r by 
deleting all simplified matching constraints Hs and adding the rule body instance 
(j){B) into the goals. Since is simplified, we drop c=/^i from the goals as it does 
not exist in the store any more. In case of a propagated goal, step (Propagate), c^i 
remains in the goal set as well in the store and thus can possibly fire further rules 

Hp\Hs 

instances. For both (Simplify) and (Propagate) derivation step, say a a' , we 

record as side-effect the numbered constraints in the store that were propagated 
{Hp) or simplified (Hs) during the derivation step. We will elaborate on the purpose 
of side-effects when we introduce the concurrent part of the semantics. 

In step (Drop), we remove an active constraint from the set of goals, if the 
constraint failed to trigger any CHR rule. 

Rule (Solve) moves an equation goal e into the store and wakes up (reactivates) 
any numbered constraint in the store which can possibly trigger further CHR rules 
due to the presence of e. Here is a simple example to show why reactivation is 
necessary. 



rl@A(x),B(x) C{x) 



{{a = 2} 1 {A(a)#l,B(2)#2}) 



(Solve) ({^(2)#1} 1 {^(2)#1, i?(2)#2, a = 2}) 

{}\{yl(2)#l.S(2)#2} 

(Simprl) "^g ' {{C7(2)}|{a = 2}> 

For clarity, we normalize all constraints in the store once an equation is added. 
Prior to addition of a = 2, j4(a)#l, B{2)^2 cannot fire rule rl. After adding a = 2 
however, we can normalize A{a)^l to ^(2)#2, which can now fire rl with B(2)#2. 
To guarantee exhaustive rule firings, we reactivate j4(2)#2 by adding it back to the 
set of goals. WakeUp{e, Sn) represents a conservative approximation of the to be 
reactivated constraints (jPuck 2005p . Note that we treat reactivated constraints as 
propagated constraints in the side-effects. 

Figure [7] presents the concurrent part of the goal-based operational semantics. 
In the (Lift) step, we turn a sequential goal-based derivation into a concurrent 
derivation. Note that side-effects are retained. Step (Goal Concurrency) joins to- 
gether two concurrent derivations operating on a shared store, if their rewriting 
side-effects 6i and S2 are non-overlapping as defined below. 

Definition 4-1 {Non- overlapping Rewriting Side-Effects) 

Two rewriting side-effects 61 — Hpi\Hsi and S2 = Hp2\Hs2 are said to be non- 
overlapping, if and only if Hsi n {Hp2 U Hs2) — {} and Hs2 H {Hpi U Hsi) — {} 

Concurrent derivations with non-overlapping side-effects essentially simplify dis- 
tinct constraints in the store, as well as propagate constraints which are not simpli- 
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{Goal I Store) ^\\g {Goal \ Store) 



(Lift) 



(G I Sn) (G' I Sn') 



(G I Sn) (G' I Sn') 



(Gl I Hsi U Hs2 U S) v^lig (G; I Hs2 U 5) 

(Ga I Hsi U ifs2 U S) (G^ | i/si U S) 
Sl = Hpi\Hsi 82 = Hp2\Hs2 
(Goal Concurrency) Hp-, C S Hp2 C S 5 = Hpi U Hp2\Hsi U Hs2 



(Gl tbi G2 a G I /fei U/fe2US') 
ig (G( W G^tbl G I 5) 



(Closure) 



lis 



Fig. 7. G()a]-Bas(-d CHR S(-inantics (Concurront Part) 



fied by one another. The (Goal Concurrency) step expresses non-overlapping side- 
effects by structurally enforcing that simplified constraints Hsi and Hs2 match 
distinct parts of the store, while propagated constraints Hpi and Hp2 are found 
in the shared part of the store S not modified by both concurrent derivations. In 
the resulting concurrent derivation, the side-effects di and 62 are composed by the 
union of the propagate and simplify components respectively, forming 6. 

An immediate consequence is that we can execute k derivations concurrently by 
stacking them together as long as all side-effects are mutually non-overlapping. The 
following lemma summarizes this observation. 



Lemma 1 {k- Concurrency) 
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For any finite k of mutually non-overlapping concurrent derivations, 

(Gi I i/si u • ■ yjHs, u ■ • yjHsk u S) ""^^"g' (G( | {} u • • vjHs. u • • uFs, u S) 
(G, I Fsi u ■ ■ u//s, u ■ • yjHsk u S) "^"g {G[ I Fsi u • • u{} u ■ ■ ui/s, u S) 

{Gk \HsiU-- Ui/s. U ■ ■ UHsk U S) lie* (G^ | Fsi U • • Uifs. U • • U{} U 
//pi C 5* ■ -Hpi C 5* - -Hpk ^ iS" 
5 = //pi U • ■ U//« U • ■ UHpk\Hsi U ■ • UHs, U • • UHsk 

(Gi W • ■ tuG, i+i ■ ■ WGk a G I Hsi U ■ ■ UHsr U • ■ UZ/st U S) 
^■^le (G( tti ■ ■ WG; U ■ ■ i+iG^, 1+) G I .S) 

we can decompose this into k—1 applications of the (pair-wise) (Goal Concurrency) 
derivation step. 

The (Closure) step defines transitive application of the concurrent goal-based 
derivation. Because side-effect labels are only necessary for the (Goal Concurrency) 
step, we drop the side-effects in transitive derivations. 

Any concurrent goal-based derivation can be reproduced in the abstract CHR 
semantics. This correspondence result is important to make use of the concurrent 
goal-based semantics as a more systematic execution scheme for CHR. We will 
formally verify this as well as other results in the up-coming Section |4?2] First, we 
give an in-depth discussion of the more subtle aspects of the concurrent goal-based 
semantics. 

4-1 Discussion 

Most of the issues we encounter are related to the problem of exhaustive rule firings. 
For brevity, we omit side-effects in derivation steps in the following examples as they 
do not matter. 

Goal Storage, Shared Store and Single-Step Execution: Each of these issues 
affect (exhaustive) rule firings. We first consider goal storage. Suppose we would 
only store goals after execution (rule head matching). That is, we do not add the 
goals into the store during (Activate) step, but only during the (Drop) step. 

i is a fresh identifier 

(Activate') 

({c} lt>G\Sn) ^g ({c#i} WG\Sn) 
(Simplify) and (Propagate) does not apply on c#j in Sn 

(Drop') 

{{c#i} WG\Sn) (G I {c#i} U Sn) 

Then, for the CHR program 



rl@Aix),B{y) ^ C{x,y) 
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we obtain the following derivation 

{{A{1),B{2)}\{}) 

(Activate') ({^(1)} | {}) >-»||g ({^(1)#1} | {}) 

II 

(Activate') ({B{2)} \ {}) -||c; ({B(2)#2} | {}) 
{{A{1),B{2)} I {}) >-.||g ({A(1)#1,B(2)#2} I {}) 
(Drop') ({A(l)#l} I {}> -lie ({} I {A{1)#1}) 
(Drop') {{B(2)#2} | {}> ({} | {B(2)#2}> 

({A(1)#1,B(2)#2} I {}) -iia ({} I {A(1)#1,B(2)#2}> 

Initially both goals ^4(1) and .8(2) are concurrently activated. Since (Activate') 

docs not store goals immediately, both active goals arc not visible to each other 
in the store. Hence, we wrongfully apply the (Drop') step for both goals. However, 
there is clearly a complete rule head match ^(1)#1, i?(2)#2. 

Next, wc investigate the shared store issue. Suppose we allow for concurrent 
executions on (non-shared) split stores. Then, the following derivation is possible. 

(Drop) ({^#3} I {^#3,i5#2}) ({} | {^#3, £#2}> 
(Drop) ({73#4} I {B#1,D#4}) ({} | {B#1,D#4}) 

{{A#3,D#4} I {A#3,B#1,D#4,E#2}} >^||e ({} | {A#3, B#l, D#4, E#2}} 

The resulting store is a final store, there are no more goals left. However, if we 
consider the entire store {A^3, E^2, B^l, D^A}, it is clearly that goal ^#3 can 
execute rule ri and goal -D#4 can execute rule r2. We conclude that splitting of 
the store leads to "stuck" states. We fail to exhaustively fire CHR rules. 

For similar reasons, we demand that when joining concurrent executions, each 
individual execution can only make a single-step. Otherwise, we encounter again a 
stuck state. 

rl@A,B ^ C 

(PI) ({^} I {}) _||^ ({^#2} I {Am) -lie ({} I {^#2}) 
(P2) {{B} I {}) -lie ({5#3} I {5#3}) -lie ({} I {5#3}) 

{{A,B}\{}) ({}|{^#2,B#3}) 

The sequence of derivation steps (PI) first activates A which is then dropped. 

Similarly, (P2) activates B which is then dropped as well which then leads to 
the stuck state ({} | {^#2,B#3}). We clearly missed to fire rule ri. This shows 
that single-step concurrent execution are essential to guarantee that newly added 
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constraints are visible to all concurrent active goals, hence we have exhaustive rule 
firings in the goal-based semantics. 

The underlying reason for non-exhaustive firing of rules is that the goal-based 
semantics is not monotonic in its store argument. However, execution is monotonic 
in the goal argument which leads us to the next issue. 



Lazy Matching and Asynchronous Goal Execution: When executing goals, 
we lazily compute only matches that contain the specific goal and immediately 
apply such matches without concerning any further matches. For instance consider 
the following CHR program and goal-based derivation: 

rmA{x),B{y) ^ D{x,y) 

{{^(1)#4} W {^(2), ^(3)} ! {B(2)#l, B(3)#2, B(4)#3, A(1)#A}) 
{{D{1, 2)} W {^(2), A(3)} 1 {B(3)#2, i?(4)#3}) 

We have applied the rule instance yl(l)^4, 5(2)^1 independently of the existence 
of the other goals (i.e. {A{2)^A{Z)}). In the literature, such a matching scheme is 
known as a lazy matching scheme, and often implemented by variants of the LEAPS 
algorithm (|D.P. Miranker and Gadbois 1990)) . 

Lazy matching in the goal-based semantics is possible only because the goal-based 
semantics is monotonic with respect to the set of goals. The following illustrates 
this monotonicity property of goals: 



({A(l)#4} I {i?(2)#l,B(3)#2,B(4)#3,^(l)#4}) 
({7?(1,2)} I {B(3)#2,i?(4)#3}) 

({^(l)#4}tU{A(2),A(3)} I {B(2)#1,B(3)#2,B(4)#3,^(1)#4}) 
g {{D{1, 2)} W {A{2), ^(3)} I {i?(3)#2, i?(4)#3}) 

(G I Sn) (C I Sn') 
(G i+i G" I Sn) (G' 1+) G" | Sn') 



The above property essentially states that we can execute goals G without prior 
knowledge of goals G" . Because of monotonicity, we are guaranteed that future 
executions of G" will not invalidate them. 
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Monotonicity of the goals also allows us to execute goals asynchronously. For 
instance, consider the following: 

rmA{x),B{y) <^ C{x,y) 

({A(l)#l} I {^(l)#l,B(2)#2}u{^(3)#3,i3(4)#4}) 

A\S {{C{1, 2)} I {} U {A(3)#3, B(4)#4}) 

({^(3)#3} I {A(1)#1,B(2)#2}U{A(3)#3,B(4)#4}) 

-NS ({C(3, 4)} I {A{l)m, B{2)m} U {}> 
51 = {}\{v4(l)#l, B(2)#2} ^2 = {}\{A(3)#3, i?(4)#4} 
5 = {}\{A(1)#1, iJ(2)#2, ^(3)#3, i?(4)#4} 



W {^(3)#3} I {^(1)#1, B(2)#2} U {^(3)#3, B(4)#4}) 
>-.|ie ({(7(1,2)}W{C7(3,4)}|{}U{}) 

The above describes the concurrent execution of goals ^(l)=i^l and ^(3)#3. No- 
tice that in the derivations of the premise, we can ignore all goals which are not 
relevant to the derivation. For instance, execution of ^(1)#1 does not need goal 
^(3)#3 to be visible, hence the goals effectively executes asynchronously. Goals do 
however, implicitly "synchronize" via the shared store. Namely, concurrent deriva- 
tions must be chosen such that rewrite side-effects involve distinct parts of the 
store. 

4-2 Correspondence Results 

We formally verify that the concurrent goal-based semantics is in exact correspon- 
dence to the abstract CHR semantics when it comes to termination and exhaustive 
rule firings. Detailed proofs are given in the appendix. In the main text, we pro- 
vide key lemmas and proof sketches. We first introduce some elementary definitions 
before stating the formal results. 

Definitions: The first two definitions concern the abstract CHR semantics. A store 
is final if no further rules are applicable. 

Definition 4-2 {Final Store) 

A store S is known as a final store, denoted Final^{S) if and only if no more CHR 
rules applies on it (i.e. -i3S" such that S S'). 

A CHR program terminates if all derivations lead to a final store in a finite 
number of states. 

Definition 4-3 {Terminating CHR Programs) 

A CHR program V is said to be terminating, if and only if for any CHR store S, 
all derivations starting from S are finite. 

Next, we introduce some definitions in terms of the goal-based semantics. In an 
initial state, all constraints are goals and the store is empty. Final states are states 
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which no longer have any goals. We will prove the exhaust iveness of the goal- 
based semantics by proving a correspondence between final stores in the abstract 
semantics and final states of the goal-based semantics 

Definition 4-4 (Initial and Final CHR States) 

An initial CHR state is a CHR state of the form (G \ {}) where G contains no 
numbered constraints (c^n), while a final CHR state is of the form ({} | Sn) 

A state is reachable if there exists a (sequential) goal-based sequence of deriva- 
tions to this state. We write to denote the transitive closure of ^g- 

Definition 4-5 {Sequentially Reachable CHR states) 

For any CHR program V, a CHR state (G" | Sn') is said to be sequentially reachable 
by V if and only if there exists some initial CHR state (G | {}) such that (G | 
{}) -a iG' I Sn'). 

4-2.1 Correspondence oj Derivations 

We build a correspondence between the abstract semantics and the concurrent goal- 
based semantics. We begin with Theorem[2j which states the correspondence of the 
(sequential) goal-based semantics. 

Theorem 2 [Correspondence of Sequential Derivations) 

For any reachable CHR state {G\Sn), CHR state (G' | Sn') and CHR program V, 
if (G I Sn) (G' I Sn') 

then {NoIds{G) W DropIds{Sn)) = {NoIds{G') W DropIds{Sn')) V 
{NoIds{G) W DropIds{Sn)) {NoIds{G') W DropIds{Sn')) 

where Nolds — {c \ cG G, cisa CHR constraint} W {e | e G G, e is an equation} 

The above result guarantees that any sequence of sequential goal-based deriva- 
tions starting from a reachable CHR state either yields equivalent CHR abstract 
stores (due to goal-based behavior not captured by the abstract semantics, namely 
(Solve) (Activate), (Drop)) or corresponds to a derivation in the abstract semantics 
(due to rule application). A goal-based semantics state (G | Sn) is related to an 
abstract semantics store by removing all numbered constraints in G and unioning 
it with constraints in Sn without their identifiers. The theorem and its proof is a 
generalization of an earlier result given in (jPuck 2005^ . 

We formalize the observation that the goal context can be extended without 
interfering with previous goal executions. 

Lemma 2 {Monotonicity of Coals in Goal-based Semantics) 

For any goals G,G' and G" and CHR store Sn and Sn', If (G | Sn) {C \ Sn') 
then (G W G" | Sn) (G' tt) C" \ Sn'). 

Next, we state that given any goal-based derivation with side-eff'ects S, we can 
safely ignore any constraints (represented by ^2) in the store which is not part of 
6. 
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Lemma 3 {Isolation of Coal-based Derivations) 

If {C\HpUHsLlSiLI S2) "^g' {C \HpiJS[iJ S2) 

then {C I HpUHsU Si) {C \ Hp U S[) 

Lemma |3] can be straight-forwardly extended to multiple derivation steps. This 
is stated in Lemma 21 

Lemma 4 {Isolation of Transitive Coal-based Derivations) 

li{C \ HpU HsU SiU S2) {C \ HpU S{U 5'2)with side-effects S = Hp\Hs then 
(G I HpU HsU Si) >-^*g (C I Hp U Si) 

The next states that any concurrent derivation starting from a reachable CHR 
state can be replicated by a sequence of sequential goal-based derivations. Lemma 
[S]is the first step to prove the correspondence of concurrent goal-based derivations. 

Lemma 5 {Sequential Reachability of Concurrent Derivation Steps) 

For any sequentially reachable CHR state a, CHR state a' and rewriting side-effects 

(5 if cr ^\\g <j' then a' is sequentially reachable, a a' with side-effects 5. 



Proof 

(Sketch) Via Lemma [1] we can always reduce k mutually non-overlapping concur- 
rent derivations into several applications of the (Goal Concurrency) step. Hence we 
can prove Lemma [5] by structural induction over the concurrent goal-based deriva- 
tion steps (Lift) and (Goal Concurrency) where we use Lemmas [2] and |4] to show 
that concurrent derivations can always be replicated by a sequence of sequential 
goal-based derivations. □ 



Theorem 3 {Sequential Reachability of Concurrent Derivations) 

For any initial CHR state u, CHR state a' and CHR Program V, if (t ^\\g then 

cr >-^g a . 

The above follows directly from Lemma [S] by converting each single step concur- 
rent derivation into a sequence of sequential derivations, and showing their com- 
posibility. 

From Theorem [5] and |31 we have the following corollary, which states the cor- 
respondence between concurrent goal-based CHR derivations and abstract CHR 
derivations. 

Corollary 1 {Correspondence of Concurrent Derivations) 

For any reachable CHR state {C \ Sn), CHR state (C | Sn') and CHR program V, 
if (G I Sn) (G' I Sn') 

then {NoIds{C) W DropIds{Sn)) = {NoIds{C') U DropIds{Sn')) V 
{NoIds{C) U DropIds{Sn)) {NoIds{C') W DropIds{Sn')) 

where Nolds = {c| cG G, cisa CHR constraint} l+l {e | e G G, e is an equation} 
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4-2.2 Correspondence of Termination 

We show that all derivations from an initial state to final states in the concurrent 
goal-based semantics correspond to some derivation from a store to a final store in 
the abstract semantics. We first define rule head instances: 

Definition 4-6 {Rule head instances) 

For any CHR state a = {G,Sn) and CHR program V, any {Hp U Hs) C Sn is 
known as a rule head instance of a, if and only if 3{r@Hp\Hp tg \ B) E 
Eqs{Sn) [^(pAtg and (j){H^ W _ff^) = DropIds{Hp U Hs). 

Definition 4.1 {Active rule head instances) 

For any CHR state a = {G, Sn) and CHR program V, a rule head instance H of 
a is said to be active if and only if there exists at least one c#z G G such that 
c#i e H. 

Rule head instances (Definition I4.6P are basically minimal subsets of the store 
which matches a rule head. Active rule head instance (Definition 14. 7p additional 
have at least one of it is numbered constraint in the goals as well. Therefore, by 
the definition of the goal-based semantics, active rule head instances will eventually 
be triggered by either the (Simplify) or (Propagate) derivation steps. 

Lemma 6 {Rule instances in reachable states are always active) 

For any reachable CHR state {G \ Sn), any rule head instance H C Sn must be 

active, i.e. 3c#i £ H such that c^i G G. 

Lemma [6] shows that all rule head instances in reachable states are always active. 
This means that by applying the semantics steps in any way, we must eventually 
apply the rule head instances as long as all it is constraints remain in the store. 

Theorem |4] states that termination of a concurrent goal-based derivation corre- 
sponds to termination in the abstract semantics. This is of course, provided that 
the CHR program is terminating. 

Theorem 4 {Gorrespondence of Termination) 

For any initial CHR state (G, {}), final CHR state {{}, Sn) and terminating CHR 
program V, 

if {G I {}) -fic; ({} I Sn) 

then G DropIds{Sn) and Finalj[{DropIds{Sn)) 

We prove this theorem by first using Theorem [3] which guarantees that a con- 
current goal-based derivation from an initial state to a final state corresponds to 
some abstract semantics derivation. We next show that final states correspond to 
final stores in the abstract semantics. This is done by contradiction, showing that 
assuming otherwise contradicts with Lemma [6l 
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4-3 Concurrent CHR Optimizations 

In the sequential setting, there exist a weahh of optimizations ( Duck 2005||Schrijvers 2005] 
[Sneyers et ah 2005) to speed up the execution of CHR. Fortunately, many of these 
methods are still largely applicable to our concurrent goal-based variant as we dis- 
cuss in the following. For the remainder, we assume that each goal (thread) tries 
the CHR rules from top-to-bottom to match the rule execution order assumed in 
(IDuck 20051 ISchrijvers 20"05| [Sneyers et al. 2005D . 

Basic constraint indexing like lookups via hashtables are still applicable with 
minor adaptations. For instance, the underlying hashtable implementation must be 
thread safe. Consider the following example: 

rO@A{x, y),B{x), C{y) x > y \ D{x, y) 

Suppose we have the active constraint ^(l,2)#n. To search for a partner con- 
straint of the form B{l)^m and C(2)#p, standard CHR compilation techniques 
would optimize with indexing (hashtables) which allows constant time lookup for 
these constraints. The use of such indexing techniques is clearly applicable in a 
concurrent goal execution setting as long as concurrent access of the indexing data 
structures are handled properly. For example, we can possibly have a concurrent 
active constraint ^(l,3)#g which will compete with ^(l,2)#n for a matching 
partner 5(l)#m. As such, hashtable implementations that facilitate such indexing 
must be able to be accessed and modified concurrently. 

Guard optimizations /simplifications aim at simplifying guard constraints by re- 
placing guard conditions with equivalent but simplified forms. Since guards are 
purely declarative, they are not infiuenced by concurrently executing goal threads 
(i.e. CHR rules). Hence, all existing guard optimizations carry over to the concur- 
rent setting. 

The join order of a CHR rule determines the order in which partner constraints 
are searched to execute a rule. The standard CHR optimization known as optimal 
join-ordering and early guard scheduling (jPuck 2005[) aims at executing goals with 
the most optimal order of partner constraints lookup and guard testing. By optimal, 
we refer to maximizing the use of constant time index lookup. Considering the same 
CHR rule (rO) above, given the active constraint B{x), an optimal join-ordering 
is to lookup for A{x,y), schedule guard x > y, then lookup for C{y). Since our 
concurrent semantics does not restrict the order in which partner constraints are 
matched, optimal join ordering and early guard scheduling are still applicable. 

Another set of optimizations tries to minimize the search for partner constraints 
by skipping definitely failing searches. Consider the following example: 



rl@A 
r2@A,j 




If the active goal A cannot fire rule (rl) then we cannot fire rule (r2) either. Hence, 
after failing to fire rule (rl) we can drop goal A. Thus, we optimize away some 
definitely failing search. This statement is immediately true in the sequential setting 
where no other thread affects the constraint store. The situation is different in a 
concurrent setting where some other thread may have added in between the missing 
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constraint A. Then, even after failing to fire (rl) we could fire rule (r2). However, we 
can argue that the optimization is still valid for this example. We will not violate the 
important condition to execute CHR rules exhaustively because the newly added 
constraint A will eventually be executed by a goal thread which then fires rule (rl). 
Hence, the only concern is here that the optimization leads to indeterminism in the 
execution order of CHR rules which is anyway unavoidable in a concurrent setting. 

Yet there are existing optimizations which are not applicable in the concurrent 
setting. For example, continuation optimizations (jPuck 20051 [Schrijvers 2005 1 are 
not entirely applicable. Consider the following CHR rule: 

r4@^(a;), A{y) <=^ x y \ ■ ■ ■ 

Given an active constraint A{l)^n, fail continuation optimization will infer that 
if we fail to fire the rule with A{l)^n matching A{x), there is no point trying to 
match it with A{y) because it will most certainly fail as well, assuming that the 
store never changes. In a concurrent goal execution setting, we cannot assume that 
the store never changes (while trying to execute a CHR). For instance, after failing 
to trigger the rule by matching A{l)^n with A{x), suppose that a new active goal 
j4(l)#m is added to the store concurrently. Now when we match A(\)^n to A{y) 
we can find match the partner j4(l)#m with A{x), hence breaking the assumptions 
of the fail continuation optimization. 

Late (also known as delayed) storage optimization ()Duck 2005P aims at delaying 
the storage of a goal g, until the latest point of its execution where g is possibly a 
partner constraint of another active constraint. Consider the following example: 

rmPi =^ Q 
r2@P2, R 
r3@P3, Rl 4=^ True 
rmPi =^ S 
r5@P5,Si True 

Note to distinguish the rule heads, we annotate each rule head with a subscript 
integer (eg. P^). With late storage analysis techniques described in (jPuck 2005^ . 
we can delay storage of an active constraint P until just before the execution of the 
body of r4. This is because the execution of goal S (obtained from firing of r4) can 
possibly trigger r5. While this is safe in the sequential goal execution scheme, it 
is possible that rule matches are missing in the concurrent goal execution setting. 
Consider the case where we have some simultaneously active goals P#n and T^m. 
Since P=f/=n is only stored when its execution has reached r4, the match r2 can be 
missed entirely by both active parallel goals P^/^n and T^m. Specifically, this 
happens if goal T=f^m is activated only after has tried matching with P2 

(of r2), but completes goal execution (by trying Ti of r2, and failing to match) 
before goal P^^n is stored. Hence, we conclude that we cannot safely implement 
late storage in the concurrent setting. 



5 Related Work 



We review prior work on execution schemes for CHR and production rule systems. 
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5.1 CHR Execution Schemes 

There exists a wealth of prior work on the semantics of CHR. We refer to ( [Sneyers et al. [ ) 
for a comprehensive summary. Our focus here is on the operational CHR semantics 
and we briefly review the most relevant works. 

The theoretical (a.k.a. high-level) operational semantics (jFriihwirth 1998P is de- 
rived from the abstract semantics and inherits its high degree of indeterminism. 
The theoretical semantics has been mainly used for the study of high-level prop- 
erties such as confluence (jAbdennadher 19971 lAbdennadher et al. 1999[l . Conflu- 
ence analysis has been exploited to study the degree of concurrency in CHR pro- 
grams (jFriihwirth 20051 [Schrijvers and Sulzmann 2008 1 . None of these works how- 



ever provide direct glues how to systematically execute concurrent programs. 

In Puck et al. 2004| IDe Koninck et al. 20081 IDe Koninck et al. 2008"| some sys- 
tematic, highly deterministic semantics have been developed to achieve efficient im- 
plementation schemes. However, these semantics are inherently single-threaded. Our 
motivation is to obtain systematic yet concurrent semantics which led us to develop 
the goal-based concurrent semantics presented in this paper. In the special case of a 
single goal thread, our semantics is equivalent to the refined operational semantics 
given in (jPuck et al. 20041 IDe Koninck et al. 20081 IDe Koninck et al. 2008) . 

There are only few works which explore different semantics, other than the theo- 
retical or abstract semantics, to address concurrency. The work in (ISarna-Starosta and Ramakrishnan 2007^ 
adopts a set-based semantics and supports tabled, possible concurrent, rule execu- 
tion. This execution scheme is not applicable to CHR programs in general which 
usually assume a multi-set based semantics. The recent work in (jBetz et al. 2009P 
takes a new stab at concurrency by introducing the notion of persistent constraints. 
The idea is to split the store into linear (multi-set like) and persistent (set like) con- 
straints. We are not aware of any evidence which shows that this approach supports 
effective concurrency in practice. Our approach leads to an efficient parallel imple- 
mentation as we explain in the next section. 



5.2 From Concurrent to Parallel CHR Execution 

In our earlier works (jLam and Sulzmann 20071 ISulzmann and Lam 2008|) we have 
developed a parallel CHR implementation scheme based on an informally described 
concurrent goal-based execution scheme, see Section 3 in (jSulzmann and Lam 20081) . 
The present works provides a concise formal treatment of the implemented con- 
current goal-based execution scheme. In our implementation, multiple threads, 
each executing a unique CHR goal, are executed in parallel on multiple processor 
cores. Parallel goal executions are largely asynchronous, only implicitly synchroniz- 
ing via the shared constraint store. Atomic CHR execution is guaranteed via ad- 
vanced synchronization primitives such as Software Transactional Memory. We refer 
to (jSulzmann and Lam 20081) for a thorough description of the more subtle imple- 
mentation details. Our experimental results reported in (jSulzmann and Lam 20081) 
show that we achieve good scalability when the number of processor cores increases. 
The overhead of the parallel implementation is fairly minor compared to a single- 
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Parallel Matching (Match) 



Parallel Conflict Resolution (CR) 



Parallel Rule Application (Act) 



Fig. 8. Parallel Production Rule Execution Cycles 



threaded implementations thanks to the use of lock-free algorithms. Optimization 
methods applicable in the concurrent/parallel setting are discussed in the earher 
Section SSI 



5.3 Parallel Production Rule Systems 

Parallel execution models of forward chaining production rule based languages (e.g. 
0PS5 ( Forgy and McDermott 1977[ )) have been widely studied in the context of 



production rule systems. A production rule system is defined by a set of multi- 
headed production rules (analogous to CHR rules) and a set of assertions (analogous 
to the CHR store). Production rule systems are richer than the CHR language, 
consisting of user definable execution strategies and negated rule heads. This makes 
parallelizing production rule execution extremely difficult, because rule application 
is not monotonic (rules may not be applied in a larger context). As such, many 
previous works in parallel production rule systems focuses on efficient means of 
maintaining correctness of parallel rule execution (e.g. data dependency analysis 
(jlshida 1991 1 , sequential to parallel program transformation ([Gamble 1990P ) , with 
respect to such user specified execution strategies. These works can be classified 
under two approaches, namely synchronous and asynchronous parallel production 
systems. 

For synchronous parallel production systems (e.g. UMPOPS ( [Gupta et al. 1988] )), 
multiple processors/threads run in parallel. They are synchronized by execution cy- 
cles of the production systems. Figure [8] illustrates the production cycle of a typi- 
cal production rule system, consisting of three execution phases. In the (Match) 
phase, all rule matches are computed. Conflict resolution (CR) involves filtering 
out matches that do not conform to the user specified rule execution strategy, 
while (Act) applies the rule matches that remains (known as the eligible set) after 
the (CR) phase. By synchronizing parallel rule execution in production cycles, a 
larger class of user specified execution strategies can be supported since execution 
is staged. 

Matching in synchronous production rule systems often use some variant of the 
RETE network ( [Forgy 1982[ ). RETE is an incremental matching algorithm where 
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Entrance 






B(x; 


M2 




Ml = {yl(l),A(2)} M2 = {5(1),5(2)} M3 = {C(3)} 

M4 = {{A(1),5(1)},{A(2),5(2)}} 

Ms = {{A{1), 5(1), C(3)}, {A{2), 5(2), C(3)}} 



Fig. 9. Example of a RETE network, in CHR context 



matching is done eagerly (data driven) in that each newly added assertion (con- 
straint in CHR context) triggers computation of all it is possible matches to rule 
heads. Figure IH] illustrates a RETE network (acyclic graph), described in CHR 
context. Root node is the entrance where new constraints are added. Intermediate 
nodes with single output edges are known as alpha nodes. Intermediate nodes with 
two output edges are beta nodes, representing joins between alpha nodes. Each 
alpha node is associated with a set of constraint matching its pattern, while a beta 
node is associated with a set of partial/complete matches. Parallel implementation 
of RETE ( [Mahajan and Kumar 1990] ) allows distinct parts of the network to be 
computed in parallel. 

The most distinct characteristic of RETE is that partial matches are computed 
and stored. This and the eager nature of RETE matching is suitable for produc- 
tion rule systems as assertions (constraints) are propagated (not deleted) by de- 
fault. Hence computing all matches rarely results in redundancy. Traditional CHR 
systems do not advocate this eager matching scheme because doing so results to 
many redundancies, due to overlapping simplified matching heads. Eager match- 
ing algorithms is also proved in (|D.P. Mir anker and Gadbois 1990]) to have a larger 
asymptotic worst-case space complexity than lazy matching algorithms. 

In (jMiranker 1990p . the matching algorithm TREAT is proposed. TREAT is 
similar to RETE, except it does not store partial matches. TREAT performs better 
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than RETE if the overhead of maintaining and storing partial matches outweighs 
that of re-computing partial matches. 

Asynchronous parallel production rule systems (e.g. Swarm (jGamble 1990p . OREL 
([Miranker et al. 1989p ) introduce parallel rule execution via asynchronously run- 
ning processors/threads. In such systems, rules can fire asynchronously (not syn- 
chronized by production cycles), hence enforcing execution strategies is more dif- 
ficult and limited. Similar to implementations of goal based CHR semantics rule 
matching is such systems often use a variant of the LEAPS ()D.P. Miranker and Gadbois 1990]) 
lazy matching algorithm. 

5.3.1 Observations 

Staging executions in synchronous parallel production rule systems allows for flexi- 
bility in imposing execution strategies, but at a cost. In (jNeiman 1991|) . synchronous 
execution of UMPOPS production rule system is shown to be less efficient than 
asynchronous execution. Hence it is clear that synchronous systems will only be 
necessary if we wish to impose some form of execution strategies on top of the 
abstract CHR semantics (e.g. rule-priority, refined operational semantics). We are 
interested in concurrent CHR semantics on the abstract CHR semantics. Its non- 
determinism and monotonicity property provides us with the flexibility to avoid 
executing threads in strict staging cycles. Thus our approach is very similar to 
asynchronous parallel production rule systems. 

Lazy matching in single-threaded CHR execution is the best choice, since we 
only ever have one thread of execution and wish to avoid computing overlapping 
(redundant) rule head matches. No doubt that in a parallel setting, eager matching 
(like RETE, TREAT) may be more optimal if the executed CHR program consist 
of rules with more propagated heads. This is because we compute more matches 
in parallel with brute force (find all match) parallelism and we can get away with 
less redundancy. Yet to cater for the general case (more simplified heads), we again 
choose lazy matching. 

We therefore conclude that the goal-based execution model of CHR is still the 
ideal choice for a parallel implementation of the abstract CHR semantics. For CHR 
with rule priorities or refined CHR operational semantics, a variant of the syn- 
chronous parallel production rule execution is a possible choice. We leave this topic 
for future work. 

6 Conclusion 

We have introduced a novel concurrent goal-based CHR semantics which is inspired 
by traditional single-threaded (sequential) goal-based CHR execution models. Ex- 
isting CHR semantics aim at introducing specific execution strategies (e.g. ordered 
goal execution, rule priorities) on top of the CHR abstract semantics, hence adding 
more determinism. In contrast, the concurrent goal-based CHR semantics exploits 
the inherent non-deterministic and concurrent abstract CHR semantics, while intro- 
ducing a systematic goal-based execution strategy. We have shown that all concur- 
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rent derivations can be replicated in the sequential goal-based semantics and that 
there is a correspondence between the sequential goal-based semantics and the ab- 
stract CHR semantics. Thus, establishing correctness of our concurrent goal-based 
CHR semantics. Our semantics provides the basis for an efficient parallel CHR 
implementation. The details are studied elsewhere (jSulzmann and Lam 2008"| . 

An interesting question is how our concurrent semantics can help to parallelize an 
existing single-threaded semantics such as (jPuck et al. 2004"| . We leave the study 
of this issue for future work. 
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7 Proofs 

In this section, we provide the proofs of the Lemmas and Theorems discussed in 
this paper. Because many of our proofs rely on inductive steps on the derivations, 
we define fc-step derivations to facihtate the proof mechanisms. Figure [TU] shows 

fe-step derivations of the sequential goal-based derivations >~*g and the concurrent 

s 

goal-based derivations ^||c;- 

7.0.2 Proof of Correspondence of Derivations 

Theorem [2] (Correspondence of Sequential Derivations) For any reachable 
CHR state {G \ Sn), CHR state (G" | Sn') and CHR Program V, 

if (G I 5"^) (G" I Sn') 

then (NoIdsiG) W DropIds{Sn)) = {NoIds{G') tt) DropIds{Sn')) V 
(NoIdsiG) W DropIds{Sn)) >~^*j^ {NoIds{G') W DropIds{Sn')) 

where Holds — {c\ cG GjC is a CHR constraint} l±){e|eeG,eisan equation} 

Proof 

We prove that for all finite n and reachable states {G \ Sn), (G" | Sn'), {G \ Sn) 
(G" I Sn') either yields equivalent abstract stores or corresponds to some abstract 
semantics derivation. We prove by induction on the derivation steps n. Showing that 
goal-based derivation of any finite n steps satisfying one of the following conditions: 

(CI) {NoIds{G) W DropIds{Sn)) = {NoIds{G') W DropIds{Sn')) 
(C2) {NoIds{G) W DropIds{Sn)) >~>\ {NoIds{G') W DropIds{Sn')) 

We have the following axioms, by definition of the functions Nolds and Droplds, 
for any goals G or store Sn: 

(al) For any equation e, NoIds{{e} l±) G) = {e} 1+) NoIds{G) 

(a2) For any equation e, DropIds{{e} U Sn) = {e} W DropIds{Sn) 

(a3) For any numbered constraint c#j, NoIds{{c4f^i} ttJ G) = NoIds{G) 

(a4) For any numbered constraint c^i, DropIds{{c^i}U Sn) = {c}[ti Droplds (Sn) 

(a5) For any CHR constraint c, NoIds{{c} l±) G) = {c} l±) NoIds{G) 

(a6) For any store Sn' , DropIds{Sn U Sn') = DropIds{Sn) l±) DropIds{Sn') 

(al) and (a2) are so because Nolds and Droplds have no effect on equations. (a3) 
is true because Nolds is defined to drop numbered constraints. (a4) is true because 
Droplds is defined to remove identifier components of numbered constraints. We 
have (a5) because Nolds has no effect on CHR constraints. By definition of Droplds, 
(a6) is true. 

Base case: We consider (G | Sn) >-^g (G' | Sn'). By definition of >-»g, we 
have G = G' and Sn = Sn' . Hence {NoIds{G) W DropIds{Sn)) ^ {NoIds{G') W 
DropIds{Sn')) and we are done. 

Inductive case: We assume that the theorem is true for some finite A: > 0, hence 
(G I Sn) ^g (G' 1 577.') have some correspondence with the abstract semantics. 
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Wc now prove that by extending these k derivations with another step, we pre- 
serve correspondence, namely (G | Sn) {G' \ Sn') {G" | Sn") has a 
correspondence with the abstract semantics. We prove this by considering all pos- 
sible form of derivation step, step k + 1 can take: 

• (Solve) k + 1 step is of the form ({e} W G'" \ Sn') y^g {W \£ G'" \{e}U Sn') such 
that for some G'" and W 

G' = {e} W G'". G" =W\±) G'" and Sn" = {e} U Sn' (a^oive) 

where e is an equation, W = WakeUp{e, Sn) contains only goals of the form c#i. 
This is because (Solve) only wakes up stored numbered constraints. Hence, 

NoIds{G") W DropIds{Sn") = NoIds{ W tbi G'") tb) DrovIds{{e] U Sn') (a,oive) 

= NoIds{G"') W DropIds{{e} U Sn') (a3) 

= NoIds{G"') W {e} tt) DropIds{Sn') (a2) 

= NoIds{{e} W G'") W DropIds{Sn') (al) 

= NoIds{G') W DropIds{Sn') (asoWe) 

Hence we can conclude that the evaluated store of derivation step fc + 1 is equivalent 
to abstract store of evaluated store of step fc, therefore satisfying condition (CI). 

• (Activate) fc + 1 step is of the form ({c}W G"" | Sn') >-ig ({c#i}WG"' | {c#i}USn') 
such that for some G'" 

G' = {c} ttl G'", G" = {c#i} l±) G'" and Sn" = {c#i} U Sn' (aact) 

Hence, 

NoIds{G") W DropIds{Sn") 

= NoIds{{c#i} W G'") ttl DropIds{{c#i} U Sn') (aact) 



= NoIds{G"') i±) DropIds{{c#t} U Sn') (a3) 

= NoIds{G"')iil{c}iSDropIdsiSn') (a4) 

= NoIds{{c} IS G'") i±) DropIds{Sn') (a5) 

= Nolds ( G' ) l±) Droplds {Sn') (aact ) 



Hence we can conclude that evaluated store of derivation step fc + 1 is equivalent 
to abstract store of evaluated store of step k, therefore satisfying condition (CI). 

• (Simplify) A; + 1 step is of the form {{c#i} W G'" | Hp U {c#«} U Hg U Sn'") y^g 
{B W G'" I Hp U Sn'") for some Hp,Hs and B such that for some G'" and Sn'" 

Sn' = HpU {c#i} UHsU Sn'", Sn" = HpU Sn'", 
G' = {c#i} W G'" and G" = B W G'" (alsimp) 
and there exists a CHR rule r@Hp\Hg tg \ B' such that exists (p where 

DropIds{{c#i} U Hs) = (t>{H's) DropIds{Hp) = (j){H^) 
Eq{Sn"')^<i)Mg B = ct>{B') (a2si™p) 

Hence, 

NoId{G') 1+1 DropIds{Sn') 

= NoIds{{c#i} 1+) G'") 1+) DropIds{Hp U {c#i} U Hs U Sn'") (alsimp) 
= NoIds{G"') ttl DropIds(Hp U {c#i} U i/s U Sn'") (as) 
= Noldslo'") l±J DropIds{Hp) ttl DropIds{{c#'i} U f/s) tbi DropIds{Sn'") (ae) 
= NoIdslC") tbi 0(77^) ttl 0(77^) ttl DropIds{Sn"') (a2simp) 
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By definition of tlie abstract semantics and a2simp , we know tliat we liave the rule 
application (j){Hp)\J(t){Hg) 4>{B') Therefore, by monotonicity of CHR rewriting 
(Theorem [J) 

NoId{G') W DropIds{Sn') 

= NoIds{G"') a (l){H'p) l+l (j>{H's) ttl DropIds(Sn"') 

NoIds{G"')\^(i){B')\BDropIds{Sn"') (TheoremHJ 

= NoIds{(f){B')^G"')^DropIdslsn"') (al),(a3) 

= NoMsIg") W DropIds{Sn") (al^^p) 

Therefore, we have NoId{G) W DropIds{Sn) NoId{C') tt) DropIds{Sn') >~>^ 

NoIds{G") l±l DropIds{Sn"), such that the k + 1 goal-based derivation step satisfy 
condition (C2). 

• (Propagate) k + 1 step is of the form ({c#i} ttl G'" \ Hp U {c#i} UHsU Sn'"} 
{B l±) {c#i} l±) C" I Hp U {c#i} U Sn'") for some Hp,Hs and 5 such that for some 
G'" and 

Sn' ^HpU {c#i} U f^s U Sn" = Hp U {c#i} U Sn'", 

G' = {c#i} W G'" and G" = B W {c#i} l±) G'" (alprop) 

and there exists a CHR rule r@Hp\Hg <;==^ | B' such that exists where 

DropIds{Hs) ^ (t>{H's) DropIds{{cifi} U 77p) = </-(77;,) 

Eq{Sn'") ^(bAtg B^ 0(5') (a2prop) 

Hence, 

NoId{G') U DropIds{Sn') 

= NoIds{{c#i} y G'") tbi DropIds{Hp U {c#j} U U 5n"') (alprop) 
= NoIds{G"') W DropIds{Hp U {c#i} U U Sn'") (ag) 
= NoIds{G"') ttl DropHs({c#«} U ^fp) ttl DropIds{Hs) ttl DropIds{Sn"') (ae) 
= NoIds{G"') tiJ </.(if^) ttl ttJ DropIds{Sn"') (a2prop) 

By definition of the abstract semantics and a2simp, we know that we have the rule 
application (j){Hp)\J(t){Hg) >->_4 4>{B') Therefore, by monotonicity of CHR rewriting 
(Theorem [1]) 

NoId(G')\i} DropIds[Sn') 

= NoIds{G"') tti 0(F^) ttl (j){H's) ttl DropIds{Sn"') 



-^A NoIds{G"')\i)(l>{B')i±) DropIds{Sn"') (Theorem[T]) 

= Aro«s(0(B') ttl G'") ttl iJropHs^S'n'") (al),(a5) 

= NoIds\(t){B') ttl {c#i} tU G'") ttl DropIds{Sn"') (a3) 

= NoIds{G")\S DropIds{Sn") (alprop) 



Therefore, we have NoId{G) ttl DropIds{Sn) NoId{G') DropIds{Sn') 

NoIds{G") ttl DropIds{Sn"), such that the A; + 1 goal-based derivation step satisfy 
condition (C2). 

• (Drop) k + 1 step is of the form {{c#i} tt) G" | Sn') ({G" | 5n') such that for 
some G'" 

G" = {cif^i} C and Sn' ^ Sn" (ajrop) 

Hence, 

NoIds{G")i±l DropIds{Sn") = NoIds{{c#i} \S G') ti) DropIds{Sn') (ajrop) 

= Noldslc')^ DropIds{Sn') (a3) 



32 



Edmund S. L. Lam and Martin Sulzmann 



Hence we can conclude that evaluated store of derivation step fc + 1 is equivalent 
to abstract store of evaluated store of step k, therefore satisfying condition (CI). 

Considering all forms of A; + 1 derivation steps, (Solve), (Activate) and (Drop) 
satisfies condition bf{Cl), while (Simplify) and (Propagate) satisfy condition (C2). 
Hence we can conclude that Theorem [2] holds. □ 

Lemma [1] (fc-Concurrency) For any finite k of mutually non-overlapping con- 
current derivations, 

(Gi \HsiU-- UHs, U • • UHsk U S) "^]"g' (G( | {} U • • UHs^ U • • UHsk U S) 

(G, I Hsi U ■ • UHs, U • • UHsk U S) "^]"g' {G[ | ;fsi U • ■ U{} U ■ ■ UHsk U S) 

{Gk \ HsiU ■ ■UHs^U ■ -UHskU S) {Gi \ Hsi U ■ ■ UHs^ U ■ ■ U{} U S) 

HpiU-- UHp, U ■ ■ UHpk\Hsi U • • UHs, U • • UHsk 

(Gi tiJ ■ • tuG, tti ■ ■ WGk a G I Hsi U ■ ■ UHsi U ■ • UHsk U S) 
^]^g (Gi tti ■ • tuG,; tu ■ ■ tuG^ tti G I S) 

we can decompose this into k—1 applications of the (pair- wise) (Goal Concurrency) 
derivation step. 

Proof 

We prove the soundness of ^-concurrency by showing that k mutually non-overlapping 
concurrent derivation can be decomposed into k—1 applications of (Goal Concurrency) 
step. We prove by induction on the number of concurrent derivations k. 

Base case: k = 2. 2-concurrency immediately corresponds to (Goal Concurrency) 
rule, hence it is true by definition. 

Inductive case: We assume that for j > 2 and j < k, we can decompose 
j mutually non-overlapping concurrent derivations, into j — 1 applications of the 
(Goal Concurrency) step. We now consider j + 1 mutually non-overlapping con- 
current derivations. Because all derivations are non-overlapping, we can compose 
any two derivations amongst these j + 1 into a single concurrent step via the 
(Goal Concurrency) rule. We pick any two concurrent derivations, say the j*'' and 
U + 1)*'' (Note that by symmetry, this choice is arbitrary): 

(G, I Hsi U • • UHsj U Hs,+i U S) "^]"g (Gj | Hsi U • ■ U{} U Hs^+i U S) 

{Gj+i I Hsi U ■ ■ UHsj U Hsj+i U S) "'''t^"g^' (G;+i \HsiU-- UHs, U {} U 5) 

Hpj C 5* Hpj^i C S 

By applying the above two non-overlapping derivations with an instance of the 
(Goal Concurrency) rule, we have: 

(G,, \HsiU-- VJHs,, U S) "''^"g' (G;, I Hsi U ■ ■ U{} U 
where G^- = Gj td Gj+i G-, = Gj U Gj+i 

Hsj' = Hsj U Hsj+i Hpji = Hpj U Hpj+i 
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Hence we have reduced j + 1 non-overlapping concurrent derivations into j 
non-overlapping concurrent derivations by combining via the (Goal Concurrency) 
derivation step. 

(Gi I Fsi u ■ • yjHsj, u S) ""^^"g' (g; I {} u ■ • u S) 

(Gy \Hsi\J-- \JHsf U S) "''^"g' (G;, t Hsi U ■ ■ U{} U 5) 
5 = Hpi U ■ • UHpj,\Hsi U • • UHsf 
(Gi 1+) • ■ ttiG,/ tti G I //si U ■ ■ U//sy U 5) 

>^*ig (g; a • ■ ug;, tti G I 

Hence, by our original assumption, the above is decomposable into j — I applica- 
tions of the (Goal Concurrency) step. This implies that j + 1 concurrent derivations 
are decomposable into j (Goal Concurrency) step. □ 

Lemma [2] (Monotonicity of Goals in Goal-based Semantics) For any goals 
C,C' and G" and CHR store Sn and Sn', if (G | Sn) {C \ Sn') then (G W G" | 
Sn) >~>l {C'\iiC" I Sn') 

Proof 

We need to prove that for any finite k, if (G | Sn) (G' | Sn') we can always 
extend the goals with any G" such that (G W G" | Sn) (G' W G" \ Sn'). 

We prove this by induction on the number of derivation steps k, showing that 
for any finite i < k, goals are monotonic. 

Base case: We consider (G | Sn) {C \ Sn'). By definition of ^g, we have 
G = G' and Sn = 5"^'. Hence we immediately have (G W G" | Sn) (G' W G" \ 
Sn') 

Inductive case: We assume that the lemma is true for some finite j > 0, hence 
(G I Sn) y~ig (C I Sn') is monotonic with respect to the goals. 
We now prove that by extending these i derivations with another step, we still 

preserve monotonicity of the goals. Namely, if (G | Sn) y-^g {{g} 1+1 Gi \ Sni) ^g 

(G,+i I then (G W G" \ Sn) (G, W G" \ Sn,) ^g (G,+i W G" \ Sn,+i) 

We prove this by considering all possible form of derivation step, step i + 1*'' can 
take: 

• (Solve) Consider i + 1*'' derivation step of the form ({e} l±) G, \ Sn,) ^g ( W G | 
{e} U Sni) for some equation e and W = Wake Up {e, Sni). 

By definition, the (Solve) step only make reference to e and Sni^ hence we can 
extend Gi with any G" without affecting the derivation step, i.e. 

({e} tt) G, W G" I Sn,) -^g {W \±i G, \±) G" \ {e} U Sn,) 

Hence, given our assumption that the first i derivations are monotonic with respect 
to the goals, extending with a i + l"* (Solve) step preserves monotonicity of the 
goals. 
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(Activate) Consider z + derivation step of the form {{c}^Gi \ Sni) ({c#j}l+l 
Ci I {c^j} U Sni) for some CHR constraint c, goals Gi and store Sni. 
By definition, the (Activate) step only make reference to goal c, hence we can 
extend Gi with any G" without affecting the derivation step, i.e. 

({c} W Q W G" I Sn,) {{c#j} W W G" | {c#j} U Sn,) 

Hence, given our assumption that the first i derivations are monotonic with respect 
to the goals, extending with a i + 1*'' (Activate) step preserves monotonicity of the 
goals. 

(Simplify) Consider i + 1*'' derivation step of the form ({c#j} W G^ \ {c#j} W 77s U 
Sni) {B ^ Gi I Sni) for some CHR constraints Hs and body constraints B. 
By definition, the (Simplify) step only make reference to goal c^j, and Hs of the 
store, hence we can extend Gi with any G" without affecting the derivation step, 
i.e. 

({c#j} W G, W G" I {c#j} UHsU Sn,) ^g {B^G.W G" | Sn,) 

Hence, given our assumption that the first i derivations are monotonic with respect 
to the goals, extending with a i + 1*'' (Simplify) step preserves monotonicity of the 
goals. 

(Propagate) Consider i + l"* derivation step of the form ({c#j}l±)Gi | HsDSni) y^g 
{B y {c^j} tbi Gi I Sni) for some CHR constraints Hs and body constraints B. 
By definition, the (Propagate) step only make reference to goal c#j, and Hs of the 
store, hence we can extend Gi with any G" without affecting the derivation step, 
i.e. 

({c#j} W G, W G" I Hs U Sn,) ^g {B W {c#j} W G, W G" | Sn,) 

Hence, given our assumption that the first i derivations are monotonic with respect 
to the goals, extending with a i + f (Propagate) step preserves monotonicity of 
the goals. 

(Drop) Consider j + derivation step of the form ({c#j}l+)Gi | Sni) ^g {Gi \ Sni) 
for some numbered constraint c^j. 

By definition, the (Drop) step only make reference to goal c=ffj, while its premise 
depend on 5^^, hence we can extend goals Gi with any G" without affecting the 
derivation step, i.e. 

({c#j} W G, W G" I Sn,) ^g {G, W G" | Sn,) 

Hence, given our assumption that the first i derivations are monotonic with respect 
to the goals, extending with a i + f (Drop) step preserves monotonicity of the 
goals. 

Hence, with our assumption of monotonicity of goals for i steps, the goals are still 
monotonic for i + 1 steps regardless of the form of the i + 1*'' derivation step. □ 

Hp\Hs 

Lemma\^ (Isolation of Goal-based Derivations) If (G | Hp U Hs U 5*1 U 5*2) ^g 
(G' \HpUSiU S2) then {G\HpUHsU Si) "^g' (G' | Hp U Si) 
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Proof 

We need to show that for any goal-based derivation, we can omit any constraint of 
the store which is not a sidc-cffcct of the derivation. To prove this, we consider all 
possible forms of goal-based derivations: 

(Solve) Consider derivation of the form 

w\{} 

({e} liJ G I W[J{}uSiLlS2) y^g {W\iiG\ W U {} U {e} U SiU S2) 

Since wake up side-effect is captured in W^, we can drop ^2 without affecting the 
derivation. Hence we also have: 

w\{} 

({e} W G I WU{}uSi) y^g {W \S G \ U {} U {e} U ^i) 
(Activate) Consider derivation of the form 

({c} W G I {} U {} U 5i U 52) ^^g ({c#z} W G I {} U {} U {c#i} USiU S2) 

Since (Activate) simply introduces a new constraint into the store, we can drop 
S2 without affecting the derivation. Hence we also have: 

({c} y G I {} U {} U ^1) ^^g {{c#t} W G I {} U {} U {c#z} U S,) 
(Simplify) Consider derivation of the form 

Hp\Hs 

{{c#i}\+} G \ HpU HsU SiU S2) {B ^ G \ Hp U Si U S2) 

Since S2 is not part of the side-effects of this derivation, we can drop S2 without 
affecting the derivation. Hence we also have: 

({c#i} \S G \ Hp U Hs li Si) "^f {B\SG\Hp[J Si) 
(Propagate) Consider derivation of the form 

Hp\Hs 

{{c#i}\£G\HpUHsUSiUS2) (S tbi {c#i} W G | U ft U &) 

Since ^2 is not part of the side-effects of this derivation, we can drop ^2 without 
affecting the derivation. Hence we also have: 

Hp\Hs 

{{c#i} \£ G \ Hp U Hs U Si) ^g {B \£ {c#i} W G \ Hp U Si) 
(Drop) Consider derivation of the form 

{{c#i} W G I {} U {} U ft U ft) ^^g (G I {} U {} U ft U ft) 

(Drop) simply removes the goal c#i when no instances of (Simplify) or (Propagate) 
can apply on it. Note that its premise references to the entire store, so removing 
ft may seems unsafe. But since removing constraints from the store will not cause 
c#z to be applicable to any instances of (Simplify) or (Propagate), hence we also 
have: 



({c}WG|{}U{}Uft)^>^g(G|{}U{}Uft) 



□ 
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Lemma^ (Isolation of Transitive Goal-based Derivations) If {G \ Hp U Hs U SiU 
S2) {G' I HpUSiUS2) with side-effects 6 = Hp\Hs, then (G | HpUHsUSi) 
(G' I HpUSi) 

Proof 

We need to prove that for aU k, {G \ HpU HsU SiU S2) y^g {G' \ HpUSiU S2) 
with side-effects S — Hp\Hs we can always safely omit affected potions of the store 
from the derivation. We prove by induction on i < k. 

Base case: i = I. Consider, (G \ HpU HsU SiU S2) {G' \ HpUSiU 82). 
This corresponds to the premise in Lemma [3l hence we can safely omit 52 from the 
derivation. 

Inductive case: j > 1. we assume that for any (G | Hpi U Hsi U Sn U 821) ^g 
(G' I Hpi U U S2i) with side-effects Si = Hpi\Hsi, we can safely omit 82% from 
the derivation. Let's consider a j = i + 1 derivation step from here, which contains 
side-effects Sj ~ Hpj\Hsj non-overlapping with Si. Hence Hpj and Hsj must be in 
S2i (i.e. = Hpj U Hsj U Sij U 82,). 

(G I Hp, U Hs, U ^i, U Hpj U Hsj U U S2j) 
{G' \HpUS{,U Hpj U Hsj U Si^ U 82, ) 

^g {G"\HpUS[,U Hpj U S{j U S2j ) 

Hence consider the following substitutions: 

Hp — Hpi U Hpj Hs = Hsi U T/^j 

Si = Sii U S'lj S[ = S[i U 5^ 

S = Hp\Hs 

we have {G \ HpU HsU SiU S2j) >^g+^ (G | 77p U S'{ U ^2^) with side-effects S such 
that no constraints in S2j is in S. Hence we can safely omit S2j from the derivation 
and we have isolation for i + 1 derivations as well. □ 

Lemma\^( Sequential Reachability of Goncurrent Derivation Steps) For any sequen- 
tially reachable CHR state cr, CHR state a' and rewriting side-effects S \i a '^\\g o' 
then o' is sequentially reachable, cr a' with side-effects S. 

Proof 

From the ^-concurrency Lemma (Lemma [T]) we showed that any finite k mutually 
non-overlapping concurrent goal-based derivations can be replicated by nested ap- 
plication of the (Goal Concurrency) step. Hence, to prove sequential reachability 
of concurrent derivations, we only need to consider the derivation steps (Lift) and 
(Goal Concurrency) which sufficiently covers the concurrent behaviour of any k 
concurrent derivations. 

We prove by structural induction of the concurrent goal-based semantics deriva- 
tion steps (Lift) and (Goal Concurrency). 

• (Lift) is the base case. Application of (Lift) simply lifts a goal-based derivation 
s s 
a ^g a into a concurrent goal-based derivation a ^\\g o . Thus states a derived 
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from the (Lift) step is immediately sequentially reachable since a >^g a' implies 

• (Goal Concurrency) 

(Dl) (Gi I Hsi U Hs2 U S) ^lie (G( | {} U Hs2 U S) 
(D2) (Ga I Hsi U /fs2 U S) (G^ | i/si U {} U 5) 
<5i = Hpi\Hsi S2 — Hp2\Hs2 
Hpi C S Hp2 C 5 (5 = iJpi U Hp2\Hsi U //g2 

(Gi a G2 a G I HsiUHs2US) 
(C) ^115 (Git!JG^t!JG|5'> 

we assume that (Dl) and (D2) are sequentially reachable. This means that we 
have the following: 

(Gi I Hsi U Hs2 U S) ^* {G[ I {} U Hs2 U 5) 

with side-effects 61 = Hpi\Hsi such that Hpi C S' (aoi) 

(G2 I ifsi U Hs2 U ^) (G^ I Hsi U {} U 5) 

with side-effects 62 = Hp2\Hs2 such that Hp2 C 5 (302) 

Since both derivations are by definition non-overlapping in side-effects, we can show 
that (C) is sequentially reachable, using monotonicity of goals (Lemma [2|) and 
isolation of derivations (Lemma |3|): 

(d W Ga tt) G I HsiUHs2 U S) 
(G( W G2 tt) G I Hs2 U S) (LemmzEl aoi) 

y~^*g (G( W G^ W G I 5) (LemmEia Lemmfgl 302) 

Hence, the above sequential goal-based derivation shows that (Goal Concurrency) 
derivation step is sequentially reachable with side-effect 5. 

□ 



Theorem [3] (Sequential Reachability of Concurrent Derivations) For any 

initial CHR state tr, CHR state a' and GHR Program V, if cr ^'\\g o' then a ^g a'. 

Proof 

We prove that for all finite k number of concurrent derivation steps a ^f^g c', we 
can find a corresponding sequential derivation sequence a ^g a' . 

Base case: k = 1. We consider a o"'. From LemmaEl we can conclude that 
we have a >—>g a' as well. 

Inductive case: k> \. We consider a ^fjg f', assuming that it is sequentially 
reachable, hence we also have a >-^*g a' . We consider extending this derivation with 
the step cr' ^\\q cr" ■ By Lemma[51 we can conclude that the k+l^^ concurrent 

derivation is sequential reachable, hence a' ^g a". Hence we have a ^g a' >~*g a" 
showing that a ^fij^ cr" is sequentially reachable. □ 



38 



Edmund S. L. Lam and Martin Sulzmann 



7.0.3 Correspondence of Termination 

Lemma [6] (Rule instances in reachable states are always active) For any 

reachable CHR state (G | Sn), any rule head instance H C Sn must be active, i.e. 
3c#i e H such that c#« G G. 

Proof 

We will prove this for the sequential goal-based semantics. Since Theorem [3] states 
all concurrent derivation is sequentially reachable, this Lemma immediately applies 
to the concurrent goal-based semantics as well. 

We prove that for all finite k derivations from any initial CHR state {G \ {}}, i.e. 
('-' I {}) (G' I '5'"')! ^'11 1'ule head instances H C Sn' has at least one c#? £ H 
such that c#i e G. We prove by induction on j < A; that states reachable by i 
derivations from an initial stage have the above property. 

Base case: i = 0. Hence {G \ {}} {G' \ Sn'}. By definition, G ^ G' and 
Sn' = {}. Since Sn' is empty, the base case immediately satisfies the Lemma. 

Inductive case: i > 0. We assume that for any {G \ {}) {G' \ Sn'), all 
rule head instances H C Sn' is active, hence have at least one c^i e H such that 
c#i G G'. We extend this derivation with an i -f 1*'* step, hence (G \ {}) (G' \ 

Sn') y~^g {G" I Sn"). We now prove that all rule head instances in Sn" are active. 
We consider all possible forms of this i + 1*'' derivation step. We omit side-effects. 

(Solve) z-Kl derivation step is of the form ({e}l±)G"" | Sn') >^g {W^G"' \ {e}USn') 
for some goals G'" and W — WakeUp{e, Sn'). Our assumption provides that all rule 
head instances in Sn' are active. Introducing e into the store will possibly introduce 
new rule head instances. This is because for some CHR rule {r@Hp\Hs <;=4> tg \ 
B) G V since we may have a new such that Eqs{{e} U Sn') \= (j) A tg and 
(j){Hp U Hs) G Sn'. This means that there is at least one c#i in (jfiHp U Hs) 
which is further grounded by e. Thankfully, by definition oi W — WakeUp{e, Sn'), 
we have c#j G W. Hence new rule head instances will become active because of 
introduction of W to the goals. 

(Activate) i + 1 derivation step is of the form ({c} W G'" \ Sn') ^g ({c#i} W G'" \ 
{c^i}USn'). Our assumption provides that all rule head instances in Sn' are active. 
By adding c^i to the store, we can possibly introduce new rule head instances 
{c#i} U H such that H G Sn'. Since c#i is also retained as a goal, such new rule 
head instances are active as well. 

(Simplify) i + 1 derivation step is of the form ({c#j} W G'" \ {c#z} UHsU Sn') ^g 
{B l+l G'" I Sn'). Our assumption provides that all rule head instances in Sn' are 
active, c^i has applied a rule instance, removing c#j and some Hg from the store. 
Since c^i is no longer in the store, we can safely remove from the goals. 
Removing Hs from the store will only (possibly) remove other rule head instance 
from the store. Hence rule head instances in Sn' still remain active. 
(Propagate) z -I- 1 derivation step is of the form ({c#i}y G"" | {c#i}U77sU5'n') >^g 
{B^{c^i}^G"' I {c#j}US'n'). Our assumption provides that all rule head instances 
in Sn' are active. has applied a rule instance, removing some Hs from the store. 
Since c#? is still in the store, we cannot safely remove c#i from the goals, thus 
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it is retained. Removing Hs from the store will only (possibly) remove other rule 
head instance from the store. Hence rule head instances in Sn' , including those that 
contains c#i, still remain active. 
• (Drop) I + 1 derivation step is of the form ({c#z} W G"" | Sn') {G'" | Sn'). Our 
assumption provides that all rule head instances in Sn' are active. Premise of the 
(Drop) step demands that no (Simplify) and (Propagate) steps apply on c#i. This 
means that c^i is not part of any rule head instances in Sn' . Hence we can safely 
remove c^i from the goals without risking to deactivate any rule instances. 

Hence (Solve) and (Activate) guarantees that new rule head instances become ac- 
tive, (Drop) safely removes a goal without deactivating any rule head instances and 
(Simplify) and (Propagate) only removes constraint from the store. In all cases, 
existing rule head instances remain active while new rule head instances become 
active, thus we have proved the lemma. □ 

Theorem |4] (Correspondence of Termination) For any initial CHR state 
(G, {}), final CHR state ({}, Sn) and terminating CHR program V, 

if {G I {}) -fic; ({} I Sn) 

then G DropIds{Sn) and Finalj[(DropIds{Sn)) 

Proof 

We prove that for any concurrent derivation {G \ {}) ({} | Sn), we have a 

corresponding abstract derivation G >—>'^ DropIds{Sn). Theorem [3] states that we 
can replicate the above concurrent derivation, with a sequential derivation. Hence 
we have (G | {}) ({} | Sn). By instantiating Theorem[21 we immediately have 
G DropIds{Sn) from this sequential goal-based derivation. 

Next we show that DropIds{Sn) is a final store {Finalj({DropIds{Sn))) with re- 
spect to some CHR program V. We prove by contradiction: Suppose DropIds{Sn) 
is not a final store, hence ({} | Sn) has at least one rule head instance _ff of 'P in 
Sn which is not active, since the goals are empty. However, this contradicts with 
Lemma |6l which states that all reachable states have only active rule instances. 
Since ({} | Sn) is sequentially reachable, it must be the case that Sn has no rule 
head instances of V. Therefore DropIds{Sn) must be a final store. □ 



